Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2.2: rolls out chained Merkle shreds to 100% of mainnet slots (backport of #5088) #5098

Open
wants to merge 1 commit into
base: v2.2
Choose a base branch
from

Conversation

mergify[bot]
Copy link

@mergify mergify bot commented Feb 28, 2025

Problem

Incrementally rolling out chained Merkle shreds to mainnet.

Summary of Changes

The commit rolls out chained Merkle shreds to 100% of mainnet slots.


This is an automatic backport of pull request #5088 done by Mergify.

@mergify mergify bot requested a review from a team as a code owner February 28, 2025 13:54
ClusterType::Development => true,
ClusterType::Devnet => true,
// Roll out chained Merkle shreds to ~53% of mainnet slots.
ClusterType::MainnetBeta => slot % 19 < 10,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for the backports, can we simply set this to true? removal fine to ride master

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the point of keeping unused code around.
In particular, keeping more discrepancy between branches would introduce more risk if more changes are backported and they hit merge conflicts or something is missed out because the branches are different.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't see the point of taking extra changes to stable

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avoiding unnecessary discrepancy between branches:

In particular, keeping more discrepancy between branches would introduce more risk if more changes are backported and they hit merge conflicts or something is missed out because the branches are different.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't backport feature gate removals. this is the same class of change

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Backporting a feature gate removal will break ledger tool for slots across epoch-boundary that the feature was activated. And a feature gate removal does not need to be backported anyways. But we need to backport this change; so not sure how it makes them in the same class.

And I think keeping the backported change the same as the master branch is a better approach for the reasons mentioned earlier above. Unnecessarily causing them to digress is only asking for problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants